A computer is typically connected to one or more peripherals such as those used to access removable and non-removable media. Examples of such peripherals include hard disk drives, CD-ROM drives, digital versatile disk (DVD) drives and the like. The computer has an operating system that provides an interface between application programs and these peripherals. For example, the operating system will receive requests from an application program to access a peripheral, e.g. read data from or write data to the media. The operating system then translates the request into a form that will be understood by the peripheral. A portion of the operating system, usually called a device driver, performs this function.
In general, the operating system has access to data that allows the operating system to determine the current status of a peripheral thereby facilitating efficient communication. For example, before the operating system attempts to read from media in a DVD drive, the operating system first determines whether the DVD drive is busy completing another task. If the device is busy, the operating system may defer a request to read from the media until the drive is available and can execute the required task. To provide the operating system with current data on the status of a peripheral, the device driver periodically queries the peripheral to obtain its updated status information. The device, in turn, provides a response message with status information which the device driver forwards to the operating system as necessary.
One method by which a device driver can query a peripheral to obtain its status is by transmitting a GET EVENT/STATUS NOTIFICATION (GESN) command. The GESN command is described in the Mt. Fuji Commands for Multimedia Devices, SFF-8090i v5 standard (referred to herein as the Multimedia Devices standard). Specifically, the GESN command allows the device driver to request the status for one or more event types associated with a peripheral. Event types are used to classify the different types of events that may occur at the peripheral. For example, a media event type is used to describe events related to the insertion and removal of media e.g. a CD ROM or DVD disk.
The Multimedia Devices specification defines a plurality of event types for which the status may be requested. For example, in addition to the media event type, a device busy event type provides status information on the peripheral's ability to accept new commands. Other event types such as power management, external request and multi-host are also defined.
When a peripheral receives a GESN command, it provides a corresponding response message to the device driver. The format of the response message, which is also defined by the Multimedia Devices standard, only allows the status for one event type to be reported in a single response message and further only allows one response message per GESN command.
The status included in a response message indicates whether or not the status for the event type being reported has changed. A status of “no change” or “NoChg” for an event type means that the status has not changed since it was last reported to the device driver. Where some type of status change has occurred, the nature of that status change is included in the response message. For example, if a DVD disk is inserted into a DVD drive and becomes ready for access, the drive will report a status of “NewMedia” the next time it provides a response message for the media event type.
The device driver can request the status for multiple event types with a single GESN command. However, as discussed above, the peripheral only provides one response message per GESN command and each response message only includes the status for one event type. Each event type has a priority and the peripheral uses the assigned event type priorities to select which event type will be reported in the response message.
Unfortunately, all peripherals do not use the event priorities in a uniform manner. Some peripherals treat “NoChg” in the status of an event type as always being a reportable event. These peripherals always report the status for the highest priority event type designated in the corresponding GESN command even if the status of that event type is “NoChg.” Other peripherals treat “NoChg” as a non-reportable event as long as some type of a status change has occurred for at least one of the designated event types. These peripherals report the status for the highest priority event type that has undergone a status change.
To effectively communicate, the device driver needs to account for devices that respond to commands differently. For example, in the case of the GESN command, the device driver should issue a command such that the status of all event types is obtained regardless of how the device uses the event type priorities. Some device drivers maintain a drive list that includes the identification of the various peripheral models supported as well as data that describes how the peripheral responds to commands, such as the GESN command. The device driver identifies the peripheral model and, based on information in the drive list, tailors the way in which it communicates with the peripheral.
Drive lists suffer from numerous disadvantages. One disadvantage of drive lists is that they are both time consuming and costly to implement. There are typically thousands of models for a given type of peripheral. Each peripheral must be tested to determine how it responds to commands and the drive list must be created. Another disadvantage of using drive lists is that they become outdated as soon as another peripheral model appears on the market. Thus, the drive list must be updated and distributed if the device driver is to maintain compatibility with all available models.
From the foregoing it is apparent that an improved method of maintaining compatibility with different peripherals is needed. In particular, a method is needed that allows a device driver to obtain the status of devices that respond to status requests in different ways without the need to maintain a drive list.